IAM의Policy에대해서
안녕하세요 신입사원 김승연입니다. 벌써 입사한지 2달이 되어가네요 ^^
IAM에 관해서는 2번째 글입니다.
이번에는 공부중인 IAM의 Policy에 대해서 간단하게 정리해 보았습니다.
IAM이란
AWS Identity and Access Management(IAM)는 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다.
- IAM을 이용하면
- User
- Group
- Role
- Policy
을 이용해서 만들어진 Entity(User,Group,Role)에 policy을 적용해서 AWS리소스(EC2,S3,RDS...등)에 대한 접근을 관리하실 수 있습니다.
Policy란
AWS 의 서비스는 권한을 부여하여 Resource에 액세스할 수 없게 만들거나 할 수 있게 만들 수 있습니다. 그때 연결할 Entity(User,Group,Role)등에 자신이 원하는 권한을 정책(Policy)으로 연결하실 수 있습니다.
Policy Types
이자료를 AWS 정책 및 권한참고 하시면 Policy Types는 6가지로 분류 됩니다.
- Identity-based policies
- Resource-based policies
- Permissions boundaries
- Organizations SCPs
- Access control lists(ACLs)
- Session policies
여기서는 IAM과 관련이 있다고 생각되는 Identity-based Policies 에 대해서 중점적으로 설명하겠습니다. 그리고 IAM Role trust policy에 대해서 설명하도록 하겠습니다.
이번 글에서는 AWS IAM 권한 및 정책를 참고 하여서 크게 Identity-based policies와 Resource-based policies로 나누어 보았습니다.
- Identity-based Policies:User,Group,Role에 할당하는 IAM정책이라고 생각하시면 됩니다.
- Managed policies:AWS계정에 속한(User,Group,Role)에게 연결할 수 있는 자격 증명 기반 정책입니다.
- AWS managed policies:AWS에서 생성 및 관리하는 관리형 정책입니다.
- customer managed policies:사용자가 자신의 AWS계정에서 생성 및 관리하는 관리형 정책입니다.
- lnline policies:자신이 생성 및 관리하는 정책으로 User,Group,Role의 역할에 직접 포함되는 정책(User,Group,Role에 직접 연결해서 사용하는 정책 입니다.)
- Resource-based Policies:리소스(S3 Bucket Policy, SQS Queue Policy, VPC Endpoint Policy ... 등에서 사용됨)에 연결하는 정책이라고 생각하시면 됩니다.
-
IAM Role trust policy: Role에 연결되는 정책으로 역할을 수임할 수 있는 보안 주체 Entity를 정의하는 정책
Identity-based Policies와Resource-based Policies를 간략히 표로 정리해 보았습니다.
Identity-based Policies | Resource-based Policies | |
---|---|---|
연결하는 곳 | IAM내 User,Group,Role | AWS Resource |
사용하는 곳 | 모든 AWS서비스에 가능 | AWS Resource에 한정 |
IAM policy
IAM policy는 JSON파일로 구성 되어 있으며 여러 요소로 구성됩니다.
각요소
정책 및 권한참고
- Optional top-level elements
- Version: 정책 내에서 사용되며 정책 언어의 버전을 정의(2012-10-17:현재/2008-10-17:이전)
- ID: Id 요소는 정책 식별자(옵션)를 지정
- Statement
- SID: ID를 포함하여 Statement문들을 구분합니다.
- Effect
- Principal/NotPrincipal
- Action/NotAction
- Resource/NotResource
- Condition
Statement에 대해서
설명들이 어려워서 표로 한번 정리해 보았습니다.
Principal | Resource | Action | Effect | Condition |
---|---|---|---|---|
이대상에대해서 | 이 Resource 에 대한 | 특정 행동을 | 불허하거나 허용한다. | 조건에 따라서 |
- 알아두면 좋은것
- 나열되는 요소들의 순서는 중요하지 않습니다.(예를 들어 Resource 요소는 Action 요소 앞에 올 수 있습니다.)
- 정책에서 Condition 요소는 지정하지 않아도 됩니다.
- 동일한 정책 문에서 (Action/NotAction,Principal/NotPrincipal,Resource/NotResource) 둘 다 사용할 수 없습니다.
identity-based Policies(JSON 파일 보기)
AWS IAM 권한 및 정책의 예제입니다.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } }
- 이 정책의 내용은 (AWS계정에 속한User,Group,Role에 연결했을때)사용자가 us-east-2 리전 내의 123456789012 계정에서 Books 테이블의 모든 Amazon DynamoDB 작업(dynamodb:*)을 수행할 수 있도록 허용정책입니다.
Principal | Resource | Action | Effect | Condition |
---|---|---|---|---|
연결하는(user,group,role) | 이 Resource 에 대한 | DynamoDB행동을 | 허용한다(Allow). | (조건없음) |
Resource : us-east-2 리전 내의 123456789012 계정에서 Books 테이블의
이번 정책을 보시면 알 수 있겠지만 Principal이 빠져있습니다. Resource-based Policies와 다르게 연결하는 사용자를 암묵적으로 지정하기 때문에 설정하지 않는다고 합니다.
arn이란?: Amazon Resource 이름 AWS 리소스를 고유하게 식별합니다.
Amazon 리소스 이름(ARN)예제 입니다.
일반적인 예라고 하지만 구체적인 형식은 리소스에 따라 다르다고 하니 주의해주시길 바랍니다.
arn:partition:service:region:account-id:resource-id
- partition: 리소스가 있는 파티션(AWS리전의 그룹)이라고 합니다.각 AWS 계정은 하나의 파티션으로 범위가 지정됩니다.
- aws: 표준 리전
- aws-cn: 중국 리전
- aws-us-gov: WS GovCloud (US) 리전
- service: AWS 서비스를 뜻한다고 생각하시면 됩니다. 예를들면 Amazon S3 Resource의 경우 s3 입니다.
- region: 리전 입니다. 한국이면 ap-northeast-2 입니다.
- account-id: AWS 계정의 ID입니다. AWS -> MyAccount로 들어가면 숫자들을 볼 수 있으실텐데 그정보입니다.
- resource-id: 리소스 식별자입니다.(Resource의 이름 또는 ID 또는 리소스 경로일 수 있습니다.) User면 User의 이름이겠죠 문서에서는 2가지 예를 보여주고 있습니다.
- IAM User의 경우 user/Bob
- EC2 인스턴스의 경우 instance/i-1234567890abcdef0
IAM Role trust policy(JSON 파일 보기)
IAM Role trust policy는 Role에 연결되는 정책으로 역할을 수임할 수 있는 보안 주체 Entity를 정의하는 정책입니다.
IAM -> Roles에서 확인하실 수 있습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
- 이정책의 내용은 간단합니다.
- 자신의계정의 특정권한을 -> 타인이나 자신의계정의(User,Group)에 사용할 수 있게 허락해준다.
라고 이해하시면 될 것 같습니다.
그럼
Principal | Resource | Action | Effect | Condition |
---|---|---|---|---|
상대에게 | 이 Resource 에 대한 | 행동을 | 허용한다. | (조건없음) |
로 나타낼 수 있습니다.
sts:AssumeRole의미는?
Action(행동을)이라는 의미를 생각해 봅시다.
sts:AssumeRole는 행동입니다. 누구에게? Principal(상대에게)입니다.
그럼 어떤 행동을 하는 걸까요?
쉽게 말하면 이 Role(역할)의 행동입니다. 이 Role(역할)의 행동을 맡기겠다는 의미입니다.
더 정확하게 말하면 특정 Role(Role에 결부된 권한)을 임시로 인수(Assume)한다라는 행동입니다.
그럼 Role Switch를한 User는 예를들면 Role Switch를 해Role(역할)의 권한을 받을 수 있게됩니다.
역할을 만들어 IAM 사용자에게 권한 위임문서에서는 이렇게 말하고 있습니다.
신뢰 관계를 생성한 후 IAM User 또는 신뢰받는 계정의 애플리케이션은 AWS Security Token Service(STS)AssumeRole API작업을 사용할 수 있습니다.
- STS(Security Token Service): AWS Resource에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있음
임시 보안 자격 증명이란?
단기적인 증명으로 몇분에서 몇시간 설정을 할 수 있습니다. 자격 증명이 만료되면 그 자격 증명을 사용한 API요청은 이루어지지 않습니다.(어떤 종류의 액세스도 허용하지 않는다는것)
IAM의Policy에대해서 정리해보았습니다. policy에 대한내용은 내용도 어렵지만 양도 많습니다. 처음 알아보았을때 하나하나 살펴보는 것보단 IAM에서 이용하는 policy부터 알아보았고 그내용을 공유하고 싶어서 정리해보았습니다.